Could this help characterize the chips or do we need nm-scale views? https://sipeed.com/nanoxray

Archit3ch (George)

Could this help characterize the chips or do we need nm-scale views? https://sipeed.com/nanoxray

14 line pairs per mm is too low

@Tholin are any of the chips from run 2 physical characterization? Is anyone planning to do more physical characterization as part of run 3? It would be good to get as many physical performance questions answered as possible on run 3 so that we can make highly accurate simulations

@baragonaru - There are some characterization looking projects see on https://github.com/wafer-space/ws-run2 but I don't know the full details.

GitHub - wafer-space/ws-run2: wafer.space GF180MCU Run 2

wafer.space GF180MCU Run 2. Contribute to wafer-space/ws-run2 development by creating an account on GitHub.

1

Tim 'mithro' Ansell

@tnt - Poke me again about the etest data as well

Poke

1

https://scholar.google.com/scholar_url?url=https://ieeexplore.ieee.org/abstract/document/11702674/&hl=en&sa=X&d=12798520430249092438&ei=YNTAataONJGkieoPqs2OEQ&scisig=ACTRDVGKyTdyKsVzanZvl1H3BAYL&oi=scholaralrt&hist=pDTwJe4AAAAJ:9118335976713056148:ACTRDVFqsYIhyF3LLq7xnLDMkrdF&html=&pos=0&folt=kw-top - Anyone have access?

I think @Matt Venn has IEEE. Although I don't expect much from that article, from the abstract it just seem to be the digital part, so just a big bunch of RTL they ran through OL2 ...

Reminds me of https://tinytapeout.com/chips/ttgf0p2/tt_um_BLE_RX

101 SCµM-BLE-RX - Tiny Tapeout

Digital Baseband for SCµM3 BLE

even if you have ieee membership (I had one for around 20 years) articles still may be inaccessible without further purchase. it is best if you have a friend in a university as they typically have the ability to read most all of the articles via the library system.

4:21 p.m.

another route is to contact the author directly as they will typically share the article.

Ah do you need access to the article

6:13 p.m.

Well I have access to it thanks to university IP?

6:14 p.m.

I'll dm if you need it

I don't actually need access to the article (as I'm unlikely to find the time to read it and even then I'm not the right person to judge if their work is actually interesting), was mostly interested to see if their work was published on a git repo somewhere and what they achieved at a high level.

https://github.com/sifferman/gf180mcu_schematics

GitHub - sifferman/gf180mcu_schematics

Contribute to sifferman/gf180mcu_schematics development by creating an account on GitHub.

1

experiment with DFFs which use the charge in the gate capacitance to store a bit

https://www.crowdsupply.com/wafer-space/gf180mcu-run-3/updates/a-need-for-speed-tholins-own-standard-cell-library Would such DFF require a minimum clock rate ? aka be dynamic only ?

Yes

1

@kris Something sounds off in the "An Extra Bit?" section of the SRAM post. It says "why they didn’t provide a 1 KiB macro " ... well they did.

1:11 p.m.

And the table even lists it ... They didn't provide an 8 KiB macro.

1:14 p.m.

or the table is wrong but in the same article "KiB" ought to be the same unit.

@tnt thanks for flagging that, i'll go back and double check it

@kris is the area really the exact same for the two small Tim Edwards macros? the 0.5 and the 2 KiB?

ah i must've copied the wrong results, the 2KiB is correct but the 0.5KiB should be 45860.87µm² - thanks @thomasflummer and sorry for the mistake!

1

tnt

And the table even lists it ... They didn't provide an 8 KiB macro.

you're correct, i was talking about word depth of the macro but used the wrong units - it should read "why they didn't provide an 8 KiB macro". i've sent off some corrections to clarify it, and in other spots where it might be confusing. thanks for spotting that

We are talking about the fact that the foundry SRAMs didn't include a sram1024x8 version, which Tim created for his library, right? But isn't that largest size exactly exactly 1 KiB (= 1024 Byte)? The image description even says so: "Render of Tim's 1 KiB SRAM Macro". The "Capacity (KiB)" column in the table should probably say "Capacity (Kib)" (note the small b for bit) or divide the values by 8, which I would prefer.

Leo Moser (mole99)

We are talking about the fact that the foundry SRAMs didn't include a sram1024x8 version, which Tim created for his library, right? But isn't that largest size exactly exactly 1 KiB (= 1024 Byte)? The image description even says so: "Render of Tim's 1 KiB SRAM Macro". The "Capacity (KiB)" column in the table should probably say "Capacity (Kib)" (note the small b for bit) or divide the values by 8, which I would prefer.

i think i'm getting my b's and B's confused

what's the correct way of interpreting the IP name? the one you gave for example

sram1024x8 means 1024 lots of 8 bits, so 1024 bytes = 1KiB. For bits a lower case b is used (inevitably this distinction between bits and bytes is confusing!)

1

Hey all, planning on picking up wafers at 13:00 local (4hr from now) Bring your anticipation

4

Leaving to get wafers now..

2

6

3

5

The wafer.space gf180mcuD Run 1 ATBS ADC (digital core only) chip (JKU2) is alive!

We successfully brought the digital core of our (Adaptive) Threshold-Based Sampling ADC to work. For the analog front-end, we reused the PCB-level prototype from my Master's thesis. Right now, only the base functions are tested. Next, we will test the adaptive threshold functionality and proper UART communication. It was already quite late yesterday, and some measurement devices were not available.

7

1

tnt started a thread. 2026-10-09 8:45 a.m.

Leo Moser (mole99) started a thread. 2026-10-09 8:57 a.m.

Andrew Wingate

Click to see original message

Oh incredible! Hoping to hold some raw dies or otherwise get microscope shots soon. The earlier I can get a close-up of the "color" palette I taped out, the faster I can get some more "colorful" art onto my run 3 die.

1

Small update about the eFuse. I've tested two more chips with eFuse from the Run 1. All Wishbone and async eFuse blocks at 5V worked flawlesly. WB blocks also passed 5 million reads endurance test without a single failed bit. This makes 3 successfuly tested eFuse chips in total. Not much, but I assume this means that WB & async eFuse blocks are safe to use in 5V designs

. Now for the downside, current SPI efuse wrapper contains an error which might lead to hold violations and SPI interface not functioning properly in some cases. So please do not use the current SPI eFuse IP. I'm planing to release a revised SPI wrapper in a couple of weeks, together with the 3.3V compatible eFuse IP with a separate 5V supply for writing.

2

Tholin

Oh incredible! Hoping to hold some raw dies or otherwise get microscope shots soon. The earlier I can get a close-up of the "color" palette I taped out, the faster I can get some more "colorful" art onto my run 3 die.

I am not sure how we're doing things this run. As we only got a partial on die things are a little different on sending a few die to everyone. I will try to get some microscope shots sooner than later. I'll also pick one of yours off and try to get a video though my scope to try to give idea of real life look.

That would be good, thank you

12:48 p.m.

This is not going to be an exact science anyways, so, any close-ups at all helps.

Anyone taping out with my SCL this run?

12:57 p.m.

The 3.3V SCL?

Tholin

Anyone taping out with my SCL this run?

We do. Also one of our Run 2 chips was based on your SCL.

Okay, because, I added more cells to the SCL after run 2. I need someone to upgrade to this new version of my SCL for their run 3 tapeout so we can verify the new cells in silicon. Of course, the risk is that you'd be including cells that are not silicon proven, even if the rest of the SCL works on our run 2 dies.

1

1:03 p.m.

But, people have reported a 10% or higher fmax improvement with the new cells.

2

1

I'm not sure if I will actually tape out anything this run, but if I do then I'd like to have a clock gate. I thought maybe I could just instantiate one from the foundry 7t library, but trying that fails in detailed placement. Maybe I could patch it into the Avalon SCL?

Jorropo

experiment with DFFs which use the charge in the gate capacitance to store a bit

https://www.crowdsupply.com/wafer-space/gf180mcu-run-3/updates/a-need-for-speed-tholins-own-standard-cell-library Would such DFF require a minimum clock rate ? aka be dynamic only ?

Dynamic only DFF's sound super dangerous and super cool at the same time

Tholin

Oh incredible! Hoping to hold some raw dies or otherwise get microscope shots soon. The earlier I can get a close-up of the "color" palette I taped out, the faster I can get some more "colorful" art onto my run 3 die.

Did you see the awesome images that @InfoSecDJ did of people's parts?

RebelMike

I'm not sure if I will actually tape out anything this run, but if I do then I'd like to have a clock gate. I thought maybe I could just instantiate one from the foundry 7t library, but trying that fails in detailed placement. Maybe I could patch it into the Avalon SCL?

It would be good to understand why it fails in detailed placement. I can't think of an actual technical reason it shouldn't work?

Tholin

Okay, because, I added more cells to the SCL after run 2. I need someone to upgrade to this new version of my SCL for their run 3 tapeout so we can verify the new cells in silicon. Of course, the risk is that you'd be including cells that are not silicon proven, even if the rest of the SCL works on our run 2 dies.

I'm very supportive of this! I would love us to get to the position where designing and iterating on our own standard cells is considered easy and normal thing to do.

9:25 p.m.

@baragonaru - Getting some of @Tholin's new / updated standard cells into your projects seems like a very good use of your silicon.

1

Tim 'mithro' Ansell

It would be good to understand why it fails in detailed placement. I can't think of an actual technical reason it shouldn't work?

Ah, I think it's just the site name in the lef. Changing that locally to match the 3v3 SCL site name has got it past that step

Tholin

Okay, because, I added more cells to the SCL after run 2. I need someone to upgrade to this new version of my SCL for their run 3 tapeout so we can verify the new cells in silicon. Of course, the risk is that you'd be including cells that are not silicon proven, even if the rest of the SCL works on our run 2 dies.

Does the current template for wafer.space include the latest version of your library? Is there already in the newest version/any future plan to add falling-edge flops with reset? (Motorola used to define things happening on the falling edge of the clock...)

There are falling-edge flops, but none with async reset. I think you’re better off avoiding async reset anyways.

3:06 p.m.

You will have to manually update, I believe

I will update the template within the next few days

thanks for the answers, guess I need to review the resets and keep the template up-to-date!

I was about to purchase a slot, but they appear to be all gone for Run 3? https://www.crowdsupply.com/wafer-space/gf180mcu-run-3/#products

wafer.space GF180MCU Run 3

Fabricate 1,000 chips of your own design

1

DeanW

I was about to purchase a slot, but they appear to be all gone for Run 3? https://www.crowdsupply.com/wafer-space/gf180mcu-run-3/#products

well, looks like all slots on the reticle have been purchased.

2

A bit sad for me personally, but excited for wafer.space taking off.

tallied up the no of slots too, numbers match on the run 2 reticle.

7:30 a.m.

i hope you get a slot on the next run!

1

Stay tuned for the Run 4 announcement (soon)

3

AFAICT a couple of big orgs bought a substantial number of slots, so they went quick.

1

7:51 a.m.

Hopefully they will end up filled with interesting stuff to use all that space

tnt

AFAICT a couple of big orgs bought a substantial number of slots, so they went quick.

DeepAI was of those companies that bought and gifted a slot.

2

8:00 a.m.

it was for some hackathon similar to Tiny Tapeout

Leo Moser (mole99)

Stay tuned for the Run 4 announcement (soon)

Run 4 is technically not a secret, but there are no dates set. https://www.crowdsupply.com/wafer-space/gf180mcu-run-4

wafer.space GF180MCU Run 4

Fabricate 1,000 chips of your own design

1

At this rate they are going to need 2 reticles.

3

Run 2 closed July 14th, so it's been about 3 months to fill a run. Matches doing 4 runs per year

Did a cross-section through the pad.

6

2

1

http://infosecdj.net/map/wafer-space/gf180mcu-ws1-xs1/infosecdj_nikpa100ncg/

What are the odds of additional slots being opened in run 3?

InfoSecDJ

Did a cross-section through the pad.

Those are super epic!

1

Agenxy

What are the odds of additional slots being opened in run 3?

I'm trying to figure out how aggressive to be on Run #4 - earliest would be like end of Jan.

2

1

Can we switch from run3 to run4 ?

I have a quarter slot on run3 but timing is tight and there seems to be a lot of demand. (edited)

Essen

Can we switch from run3 to run4 ?

I have a quarter slot on run3 but timing is tight and there seems to be a lot of demand. (edited)

I would be interested in buying your slot

Agenxy

I would be interested in buying your slot

Nice, if @Tim 'mithro' Ansell can chime in and tell us if it is possible to swap then I am tempted in taking you on it and giving myself a few extra weeks.

1

Tholin

Oh incredible! Hoping to hold some raw dies or otherwise get microscope shots soon. The earlier I can get a close-up of the "color" palette I taped out, the faster I can get some more "colorful" art onto my run 3 die.

If you could help me understand if the FC01 die has the obvious top metal traces indeed connect the pads that visually ought to be connected, I'd be quite thankful! It's the die with the (3x2)x1 (two groups 3 pads each of different pad sizes/pitches lined up on one side) and the 3x2 (a 3x2 grid of total 6 square pads diagonally on the other side) pads that's a 0.5x0.5 slot, corner-touching a 1x1 slot. It is the only die without any exposed silvery metal around it's sealring.

Essen

Nice, if @Tim 'mithro' Ansell can chime in and tell us if it is possible to swap then I am tempted in taking you on it and giving myself a few extra weeks.

I'm not planning on "supporting swapping" - but currently the way you tie a submission on https://platform.wafer.space to a crowd supply order is just by putting the ID into a text field and then it is hand verified by me.

Welcome to wafer.space …

Platform for wafer.space low cost silicon manufacturing.

Tim 'mithro' Ansell

I'm not planning on "supporting swapping" - but currently the way you tie a submission on https://platform.wafer.space to a crowd supply order is just by putting the ID into a text field and then it is hand verified by me.

Ah, so I could purchase his slot directly from him by paying him for his crowd supply order? Maybe we could work with crowdsupply to transfer the order and that way it's transparent to you?

Agenxy

Ah, so I could purchase his slot directly from him by paying him for his crowd supply order? Maybe we could work with crowdsupply to transfer the order and that way it's transparent to you?

Basically if you trust @Essen enough you two could just write up a half page of contract, have you generate that unique https://platform.wafer.space ID that needs to be filled in the crowd supply form, put that ID into the contract, basically just say that if paid by X date to specified account, seller is obligated to put specified ID into crowd supply, and if paid after should attempt to put ID into crowd supply; make it plain text (.txt file) and put the sha256 hash of the file (sha256sum contract.txt, take the hex blob) as the purpose/reference on the payment transaction. You mostly just need to trust that the seller isn't bankrupt and is not a fugitive, because the forcing incentive for complying is that you'd file in small claims if they keep the money and don't do their part. (IANAL)

Welcome to wafer.space …

Platform for wafer.space low cost silicon manufacturing.

1

Okay, I'll DM @Essen to see how we can do this safely. Thanks! @namibj !

Agenxy

Okay, I'll DM @Essen to see how we can do this safely. Thanks! @namibj !

Yep, I would be for writing a half page contract, that would re-assume me

@Agenxy (edited)

I have a sad update. My attempt to build the first self-compiling integrated circuit has most likely failed. The goal was it to make a custom RTL-to-GDSII flow tool (FeatherLane) with a focus on being lightweight, use it on RTL for a RISC-V core, tape it out, and have the chip run FeatherLane on its own RTL, re-producing its own layout. However, today I found a one-line bug in FeatherLane’s router that accesses a single byte out of the bounds of a malloc’d array. It only uses it to decide on a continue, and if it accidentally continues when its not supposed to, the only effect is a slightly uglier looking route. Its still DRC correct and electrically correct (LVS passes), but means the resulting layout is not exactly 1:1 with what I taped out. Unless I can reproduce the exact state my whole computer was in on the day I ran FeatherLane on the RTL for tapeout. The read is non-deterministic, so whether it continues or not is random. This loop is executed thousands of times.

9

3:53 p.m.

So unless I get to tape out a chip just dedicated to FeatherLane generated layouts (unlikely, considering my finances and the fact that such a chip would not be useful outside of making this accomplishment), I’ll have to accept second-best.

3:55 p.m.

This took over half a year to pull off, and now its ruined by a single bad line of code.

Tholin

So unless I get to tape out a chip just dedicated to FeatherLane generated layouts (unlikely, considering my finances and the fact that such a chip would not be useful outside of making this accomplishment), I’ll have to accept second-best.

@baragonaru / @Paul might be willing to offer you some free silicon because of how cool a full "self hosted" ASIC design flow would be. Even if not super practical, the marketing angle alone (particularly with the current world around you don't own anything) is probably worth the cost. I think @baragonaru / @Paul where also interested in further work on your standard cell library, maybe there could be some type of trade there?

definitely interested!

I can dedicate half the die to re-tapeout of the FeatherLane layouts and the other half to regular LibreLane macros using my SCL to test the new cells.

My run2 chips, using the ocd_io, may or may not have both PU and PD set on the design select inputs due to a RTL typo. What effect does that have?

At first glance there seem to be a safe guard in place.

5:45 p.m.

Seems neither is active then.

That’s a little annoying since one of my PCBs relies on the design selects having pull-ups, but I can work with that.

It's less annoying than the alternative

The resistor part is shared between the pull up and pull down so without it, it would have been a direct path from VDD to GND through a nmos and a pmos.

Tholin

My run2 chips, using the ocd_io, may or may not have both PU and PD set on the design select inputs due to a RTL typo. What effect does that have?

You might be able to setup CVC-RV to check that the pads are pull-up/pull-down without having to simulate the whole chip in spice. Let me know if you'd like to investigate.

bailey

My run2 chips, using the ocd_io, may or may not have both PU and PD set on the design select inputs due to a RTL typo. What effect does that have?

You might be able to setup CVC-RV to check that the pads are pull-up/pull-down without having to simulate the whole chip in spice. Let me know if you'd like to investigate.

If a SPICE sim with no parasitics should suffice to surface/reproduce this behavior/bug, I'd be interested in trying that to at least see full chip extraction to simulate in an at least somewhat useful way; it seems there would be a bunch of simplifications that'd spring up both at extraction/unification time (aggregating fingers like for LVS is trivial without parasitics) and for the solver (many MOS devices having a terminal hard-connected to a fixed voltage terminates current-induced voltage offsets at those nodes, which the nonlinear solver will appreciate as it (unfortunately for parasitics sim) always calculates all node voltages to a global reference).

Paul

definitely interested!

Are you/@baragonaru perhaps interested in the muxed e-test efforts? I want(ed) that to allow us to measure hundreds of dies with (analog mux, basically like on TinyTapeout, but with each DUT area much smaller relative to the amount of analog wires fed to it, and no digital MUX to each DUT) somewhat around a hundred DUTs, using a 100%-coverage-testing setup similar to the bond tester, i.e. utilizing the cheap COB packaging. (Though unlike the bond tester with a much nicer stack of benchtop multimeters than just a few bias resistors, 3 discrete analog MUX chips, and a Raspberry Pi Pico2.) The idea was to set up for having 4-wire/kelvin style access to all DUT "LEF pins" (including VDD; substrate-tied VSS is special because the substrate itself isn't isolated, so it'd only need a sense wire MUXed to not include ground bounce in the measurements) through just a pair of analog switches with routing kept separated right up to each DUT "LEF pin", enough such to handle at least most of the SCL (4 in, 1 out, VSS, GND? 13 MUX wires). Though an idea of making them a bit larger to accomodate two smaller DUTs or one big DUT, or having two MUX bus spines with the DUT area in the middle and allowing with the control logic to have slots that spread from one mux spine to the other getting both's wires, is also being considered. Xyce with likely Dakota would be used to dream up on the order of 10k to 1M sample points to measure a DUT at, using an approximation algorithm for (getting quite usefully close to) optimal experiment design with the goal being to end up with a set of bias conditions under which to test the DUT on each of the dies that approximate maximum information gain as far as all the extraction uncertainties/imprecision-compensation-factors (shapes don't print like they're drawn due to resolution limitations; we should at least cough up correction tweak factors to allow the simulation with them applied to be a VERY close match to physical reality), and SPICE model card parameters are concerned. I should probably take some care to specifically not attempt to accurately measure the "random variables" that codify local mismatch, as we're trying to create a precise model that helps us on future dies that contain these DUTs instead of our product being a model that's precisely fit to an individual test die and could thus accurately predict the measurements at random new test points/biasing conditions applied to the very die. Though the parametric statistical distributions that express this local mismatch are very much part of what we'd be trying to extract statistically significant measurements of. Because those can be used to then compute Liberty timing uncertainties (I'm not sure to what extend Liberty let alone our open tooling supports modeling statistical variations of propagation latency, nor how large those even are and whether we'd realistically even account for them or just slightly widen the timing margins), which should have some notable effect in sufficiently deep clock trees under PVT conditions that emphasize local mismatch more than global PVT (vs. usual), due to resulting clock skew between branches. The measurements would be collected at near-DC conditions (I don't really know how to realistically do it for relevantly higher ones without loosing most of the benefits of such a dense-analog-MUX-bus architecture; also such multimeters are far simpler/commodity than ones that can handle AC with anywhere near as much accuracy) and Xyce with Dakota (and/or ROL) would be used to model-fit our extraction tweakables, questionable spice model card parameters, and the "random variables" of global & local "monte carlo" mismatch modeling. While there are some effects that only "really" affect capacitance without really affecting resistance, I'd think those could be measured with more targeted-to-that test structures; gate&junction capacitance should mostly come even from the near-DC model fitting anyways.

namibj

Are you/@baragonaru perhaps interested in the muxed e-test efforts? I want(ed) that to allow us to measure hundreds of dies with (analog mux, basically like on TinyTapeout, but with each DUT area much smaller relative to the amount of analog wires fed to it, and no digital MUX to each DUT) somewhat around a hundred DUTs, using a 100%-coverage-testing setup similar to the bond tester, i.e. utilizing the cheap COB packaging. (Though unlike the bond tester with a much nicer stack of benchtop multimeters than just a few bias resistors, 3 discrete analog MUX chips, and a Raspberry Pi Pico2.) The idea was to set up for having 4-wire/kelvin style access to all DUT "LEF pins" (including VDD; substrate-tied VSS is special because the substrate itself isn't isolated, so it'd only need a sense wire MUXed to not include ground bounce in the measurements) through just a pair of analog switches with routing kept separated right up to each DUT "LEF pin", enough such to handle at least most of the SCL (4 in, 1 out, VSS, GND? 13 MUX wires). Though an idea of making them a bit larger to accomodate two smaller DUTs or one big DUT, or having two MUX bus spines with the DUT area in the middle and allowing with the control logic to have slots that spread from one mux spine to the other getting both's wires, is also being considered. Xyce with likely Dakota would be used to dream up on the order of 10k to 1M sample points to measure a DUT at, using an approximation algorithm for (getting quite usefully close to) optimal experiment design with the goal being to end up with a set of bias conditions under which to test the DUT on each of the dies that approximate maximum information gain as far as all the extraction uncertainties/imprecision-compensation-factors (shapes don't print like they're drawn due to resolution limitations; we should at least cough up correction tweak factors to allow the simulation with them applied to be a VERY close match to physical reality), and SPICE model card parameters are concerned. I should probably take some care to specifically not attempt to accurately measure the "random variables" that codify local mismatch, as we're trying to create a precise model that helps us on future dies that contain these DUTs instead of our product being a model that's precisely fit to an individual test die and could thus accurately predict the measurements at random new test points/biasing conditions applied to the very die. Though the parametric statistical distributions that express this local mismatch are very much part of what we'd be trying to extract statistically significant measurements of. Because those can be used to then compute Liberty timing uncertainties (I'm not sure to what extend Liberty let alone our open tooling supports modeling statistical variations of propagation latency, nor how large those even are and whether we'd realistically even account for them or just slightly widen the timing margins), which should have some notable effect in sufficiently deep clock trees under PVT conditions that emphasize local mismatch more than global PVT (vs. usual), due to resulting clock skew between branches. The measurements would be collected at near-DC conditions (I don't really know how to realistically do it for relevantly higher ones without loosing most of the benefits of such a dense-analog-MUX-bus architecture; also such multimeters are far simpler/commodity than ones that can handle AC with anywhere near as much accuracy) and Xyce with Dakota (and/or ROL) would be used to model-fit our extraction tweakables, questionable spice model card parameters, and the "random variables" of global & local "monte carlo" mismatch modeling. While there are some effects that only "really" affect capacitance without really affecting resistance, I'd think those could be measured with more targeted-to-that test structures; gate&junction capacitance should mostly come even from the near-DC model fitting anyways.

I want(ed) that to allow us to measure hundreds of dies with (analog mux, basically like on TinyTapeout, but with each DUT area much smaller relative to the amount of analog wires fed to it, and no digital MUX to each DUT) somewhat around a hundred DUTs, using a 100%-coverage-testing setup similar to the bond tester, i.e. utilizing the cheap COB packaging.

Awesome! I was recently having a similar idea (although about .0005% as thought out as your version

1:59 a.m.

^^ @Tim 'mithro' Ansell

@namibj - Maybe we need a channel for this type of effort? It seems like there is also a story around @Andrew Wingate and @digshadow doing some type of automated probe card type thing based on @Andrew Wingate's die sorter and @digshadow's Labsmore Microscope stuff.

1

Yeah please set something up to focus such discussions.

namibj

Yeah please set something up to focus such discussions.

#charz channel created.

Andrew Wingate

I want(ed) that to allow us to measure hundreds of dies with (analog mux, basically like on TinyTapeout, but with each DUT area much smaller relative to the amount of analog wires fed to it, and no digital MUX to each DUT) somewhat around a hundred DUTs, using a 100%-coverage-testing setup similar to the bond tester, i.e. utilizing the cheap COB packaging.

Awesome! I was recently having a similar idea (although about .0005% as thought out as your version

I think LibreLane could be convinced to do the PnR for such in a scripted fashion; the control would only really need to be a simple digital decoder anyways that takes as input a DUT ID from some digital pads and activates the corresponding MUX. There's some ideas of adding support for on-die temperature sensors to at least attempt to map thermal gradients from local heating and get decent understanding of DUT temperature notably without having to do anything fancy in terms of thermal chamber for the testing. E.g. a simple glove box style should work easily for -20 to +120 C, the cold tests using a standard freezer who's door has been replaced with a custom one that gives access for the operator glove and the measurement pass through wires and has a fan set up inside and probably some effective thermal mass (a bunch of small water bottles probably work great/easily-well-enough) that can smooth out the temperature as the compressor cycles (at least for tests that aren't at "lowest temperature the system can get to"), and probably something to dehumidify so the electronics don't catch frost (you'd rather want the electronics to be freeze-dried than to be coated in freezing condensation) but I think calcium chloride based "disposable pack" dehumidifiers should work at those temperatures. Also, a slightly modified (thermostat only, pretty much; and taking the door off and swapping it for something with the glove access and the wire feed-throughs and suitable visual access as well) convection oven should easily work for the warm testing. I can't do it myself but if we have someone who could write the librelane scripting even e.g. with me as mentor on the task, we could probably do it in time for Run3.

namibj

I think LibreLane could be convinced to do the PnR for such in a scripted fashion; the control would only really need to be a simple digital decoder anyways that takes as input a DUT ID from some digital pads and activates the corresponding MUX. There's some ideas of adding support for on-die temperature sensors to at least attempt to map thermal gradients from local heating and get decent understanding of DUT temperature notably without having to do anything fancy in terms of thermal chamber for the testing. E.g. a simple glove box style should work easily for -20 to +120 C, the cold tests using a standard freezer who's door has been replaced with a custom one that gives access for the operator glove and the measurement pass through wires and has a fan set up inside and probably some effective thermal mass (a bunch of small water bottles probably work great/easily-well-enough) that can smooth out the temperature as the compressor cycles (at least for tests that aren't at "lowest temperature the system can get to"), and probably something to dehumidify so the electronics don't catch frost (you'd rather want the electronics to be freeze-dried than to be coated in freezing condensation) but I think calcium chloride based "disposable pack" dehumidifiers should work at those temperatures. Also, a slightly modified (thermostat only, pretty much; and taking the door off and swapping it for something with the glove access and the wire feed-throughs and suitable visual access as well) convection oven should easily work for the warm testing. I can't do it myself but if we have someone who could write the librelane scripting even e.g. with me as mentor on the task, we could probably do it in time for Run3.

I am feeling a bit of information overwhelm but yes i am definitely interested in doing the best charactarizion we can as part of Run3. answer as many physical questions as we can, as accurately as we can

baragonaru

I am feeling a bit of information overwhelm but yes i am definitely interested in doing the best charactarizion we can as part of Run3. answer as many physical questions as we can, as accurately as we can

So, I can't get myself to personally script librelane to arrange such an array of analog switches and route shared bus sideways, put a digital decoder that selects a slot at the bottom, and wire to a DUT cell's boundary with wires going from the switches upwards (north). And get it to arrange slots for DUT cells along the north side of the mux array, and wire up everything in a way that passes LVS. We could use the switches from TinyTapeout though there's potential for improving effective density if they're to be actuated and arranged as full dense columns somewhat similar to how SRAM bitcells pack dense even if they're not perfected, just thanks to relying on neighbours to be DRC clean and pass certain signals and supplies along. I could probably help with that if it's something that can be done in Klayout without it breaking the librelane flow that has to use/place the switches. But see #charz . I could mentor someone who'd script librelane for that, though.

wafer.space x Tiny Tapeout - Hackaday Europe 2026 Collaboration

@everyone, we're taking a sneak peek behind the scenes of how Tiny Tapeout's open source silicon merch for Hackaday Europe 2026 was made - featuring silicon from Run #1! Check it out: https://www.crowdsupply.com/wafer-space/gf180mcu-run-4/updates/wafer-space-x-tiny-tapeout-hackaday-europe-2026-collaboration Did you go? Have you tried your board yet??

Earlier this year the wafer.space team attended Hackaday Europe 2026, and if you did too, then your swag bag had a bit of open source silicon inside!

I want to test my DACs for VGA output again on my multi-project die sponsored by Paul. Anyone want their VGA demo included on my die?

2

Tholin

I want to test my DACs for VGA output again on my multi-project die sponsored by Paul. Anyone want their VGA demo included on my die?

Consider the wafer.space tiling like that on the WSLOGO die?

I mean, of course, but there’s more VGA demos out there, right?

Hi anyone who’s interested in working with @baragonaru and the free slots DM me and I will schedule a call and listen to everything you have to say! (edited)

namibj

So, I can't get myself to personally script librelane to arrange such an array of analog switches and route shared bus sideways, put a digital decoder that selects a slot at the bottom, and wire to a DUT cell's boundary with wires going from the switches upwards (north). And get it to arrange slots for DUT cells along the north side of the mux array, and wire up everything in a way that passes LVS. We could use the switches from TinyTapeout though there's potential for improving effective density if they're to be actuated and arranged as full dense columns somewhat similar to how SRAM bitcells pack dense even if they're not perfected, just thanks to relying on neighbours to be DRC clean and pass certain signals and supplies along. I could probably help with that if it's something that can be done in Klayout without it breaking the librelane flow that has to use/place the switches. But see #charz . I could mentor someone who'd script librelane for that, though.

would you be interested in integrating your work into the analog characterization chip that fits in the remaining 1/4 of @Tholin ‘s slot from us?

Tholin

I mean, of course, but there’s more VGA demos out there, right?

VGA Nyan Cat and VGA Drop from the TT08 demos are on ttgf0p2 so should be easy to integrate: https://tinytapeout.com/chips/ttgf0p2/

Tiny Tapeout GF 0.2 - Tiny Tapeout

52 designs, closed 2025-11-24

I picked two demos with sound since I have 4 DACs on here. 3 for VGA R/G/B, 1 for audio out.

2

Paul

would you be interested in integrating your work into the analog characterization chip that fits in the remaining 1/4 of @Tholin ‘s slot from us?

probably?

1

namibj

probably?

so cool!

Tholin

I picked two demos with sound since I have 4 DACs on here. 3 for VGA R/G/B, 1 for audio out.

Heya Tholin, I’ve got a simple/small 24bit (RGB888) test pattern generator https://github.com/algofoogle/ttsky25b-analog-vga-dacs/blob/main/verilog/rtl/controller.v which I used for some DAC test tapeouts in the past. It does rely on TT inputs to select a mode (Docs are in another repo: https://github.com/algofoogle/tt08-vga-fun/blob/main/docs/info.md#how-it-works ) but @htamas adapted it with an automatic mode-cycler too (and dithering to target RGB444 outs but that part could be removed or made togglable): https://tinytapeout.com/chips/ttihp0p2/tt_um_algofoogle_vga_fun_wrapper — nothing special, but maybe useful. My plan at one stage was to get @toivoh to port a demo to my DAC scaffold and upgrade to 24b colour (edited)

8:57 p.m.

Some example (animated) patterns:

Alright, including it

Progress

3

hey @brookieoz I saw that you're an analog designer by day. Would you be interested in using Tholin's remaining slot space for an analog characterization chip for GF180

I am unfortunately swamped with work from my day job, I probably won't be able to work on anything in like the next month or three

thank you!

12:49 a.m.

@asic destroyer would you be interested in putting Kian V designs on one of our slots?

Tholin

Progress

@Tholin may I make a selfish request to be added to your test chip? A hall effect sensor? Would that be possible? Lmk if I can help somehow

If you throw me a layout, I’ll include it

1

Andrew Wingate

@Tholin may I make a selfish request to be added to your test chip? A hall effect sensor? Would that be possible? Lmk if I can help somehow

ohhhhh that sounds mighty interesting to do.

Andrew Wingate

@Tholin may I make a selfish request to be added to your test chip? A hall effect sensor? Would that be possible? Lmk if I can help somehow

let's do put down a photodiode suitable for attaching to a multimode-fiber-coupled VCSEL maybe if it's already so sensor/physics that we'd have a hall-effect?

1

Also @Tholin dithering and crosshatches do cool things with color as well

1

Yeah, that’s what I’m trying to experiment with.

New palette

Aaaand its repository time! https://github.com/AvalonSemiconductors/ws-as06

GitHub - AvalonSemiconductors/ws-as06: Multi-Project die in wafer.s...

Multi-Project die in wafer.space run 3 shuttle. Contribute to AvalonSemiconductors/ws-as06 development by creating an account on GitHub.

2

looking for someone to help out @namibj ‘s collaboration with us on @Tholin’s space on muxed e testing with librelane scripting!

Paul

looking for someone to help out @namibj ‘s collaboration with us on @Tholin’s space on muxed e testing with librelane scripting!

https://discord.com/channels/1361349522684510449/1413281558407942236/1563254615292641372

Tholin

New palette

Neat!

The antenna rules is why we can’t have nice things

3:25 p.m.

FeatherLane is now finally in a spot where the router failing is very rare

3:25 p.m.

But I’ve been spending days now trying to get the last antenna violations to go away

3:25 p.m.

Even a run where I hard-coded it to give EVERY! SINGLE! standard cell port a diode had 20 violations.

But are those diodes close to the cell inputs ? Diodes placed badly are useless. Actually they make things worse because they force to spread things appart.

Probably not?

3:30 p.m.

I just do not have the time to spend days or even weeks programming a smart diode placer and router.

Next month @Tim 'mithro' Ansell @Stephan Bökelmann and I will be talking at this event in Shenzhen, with @geonzee hosting

1

I am quadruple-wielding FeatherLanes, hoping I can find a placer seed that gives no diode violations

1

Tholin

I am quadruple-wielding FeatherLanes, hoping I can find a placer seed that gives no diode violations

What sort of CPU do you have!!

Its running on my server’s Xeon E5-1620v4

1

5:29 p.m.

FeatherLane has no multithreading

Tholin

If you throw me a layout, I’ll include it

Hey @Tholin I made a pull request. I hope everything is in order. I would like the 4 pins [T1-T4] to be broken out to the cob please. If there is budget, the other pins would be nice, but I would be happy to power on the digital part to test if needed. Background on this request, I've been working on a BLDC motor controller and while talking with @Paul I realized adding an encoder directly to the die would be super cool!! Thank you!!

Andrew Wingate

Hey @Tholin I made a pull request. I hope everything is in order. I would like the 4 pins [T1-T4] to be broken out to the cob please. If there is budget, the other pins would be nice, but I would be happy to power on the digital part to test if needed. Background on this request, I've been working on a BLDC motor controller and while talking with @Paul I realized adding an encoder directly to the die would be super cool!! Thank you!!

I’m just looking at the blackbox verilog right now and it has multiple inout pins. If these are supposed to be analog, I can not provide that as there are no free pads left. I can only provide you with digital IO.

9:32 p.m.

Also, there are no power pins in the blackbox define. Are you SURE you don’t want PDN hookups?

Tholin

I just do not have the time to spend days or even weeks programming a smart diode placer and router.

Are you using macros? There is an option to add diodes to inputs/outputs when hardening so that fewer problems occur once macros are integrated. Also long wires may require multiple diodes.

Yes, FeatherLane puts a diode next to every input and output, but the antenna decks fail even when run on just the macro.

11:36 p.m.

So, problem is inside, not outside

Andrew Wingate

Hey @Tholin I made a pull request. I hope everything is in order. I would like the 4 pins [T1-T4] to be broken out to the cob please. If there is budget, the other pins would be nice, but I would be happy to power on the digital part to test if needed. Background on this request, I've been working on a BLDC motor controller and while talking with @Paul I realized adding an encoder directly to the die would be super cool!! Thank you!!

happy to have your hall structures in whatever muxed e-test hopefully happens soon. I think it's pretty prime targeting there, actually. It should probably be not placed where the COB mezzanine obstructs the die bottom though, but otherwise, pretty perfect. At least assuming that the hookups don't need to be high-frequency.

namibj

happy to have your hall structures in whatever muxed e-test hopefully happens soon. I think it's pretty prime targeting there, actually. It should probably be not placed where the COB mezzanine obstructs the die bottom though, but otherwise, pretty perfect. At least assuming that the hookups don't need to be high-frequency.

That would be amazing! Let me know when you get closer! No need to worry about anything probably. mezzanine shouldn't matter much either I would assume

Well I meant so that it can be sandwiched in a horeshoe-like magnet that focuses the field through the COB and the sensor, to affordably test high-field regions of the desirable operating conditions. I'm talking like getting to 3~5 tesla without too-high levels of effort being needed to pull it off.

5:04 a.m.

(That's just in preparation for the testing being feasible after tape out ofc.)

I see. My use case is to just have it next to a diametrically magnetized 6mm neodymium magnet. Field strength is not too huge

Andrew Wingate

That would be amazing! Let me know when you get closer! No need to worry about anything probably. mezzanine shouldn't matter much either I would assume

I'd like oc12 to be "narrow" in the bus direction though, with "just" 4 lines fed to it from the bus (and I guess the m1 guard? No idea what that should be wired to, I guess a fifth bus pin that doesn't need to be unique between the hall sensors?)

5:06 a.m.

Yeah I know it should work with just a magnet waved near it; I'd like the e-test tapeout of it to just support measuring higher impedance as well, that's all.

namibj

I'd like oc12 to be "narrow" in the bus direction though, with "just" 4 lines fed to it from the bus (and I guess the m1 guard? No idea what that should be wired to, I guess a fifth bus pin that doesn't need to be unique between the hall sensors?)

Don't take anything I drew as a hard req. Was just trying to fit a few variations and only use a few pins. I'm open to just about anything. Classifying even a single one would probably be good enough

oh yeah I understand we'd see once the surrounding geometry is known regarding pin density along the bus (probably m4 minimum pitch actually) and DUT strip area across the bus; if there can be metal above a DUT of yours I'd probably suggest stacking several cross-wise from the bus to use the entire height in that direction, which I'd expect to be around 200~400 um.

also guard is just tied to vss

oh just ground yeah that's free

5:10 a.m.

substrate tie?

Whatever you like

yeah just figured I give you some idea on it

5:12 a.m.

btw, ayone here want to come to 40C3 but would have issues getting a ticket?

1

3

1

Shenzhen's First Open Source Silicon Meetup

@everyone, join @mithro_, @saladchap, @maxclerkwell and Biwei Xie on Wednesday 11 November 2026 at the Chaihuo Maker Space (hosted by @geonzee) for an afternoon filled with talks, silicon demos and a chance to connect with Shenzhen's hardware community! Topics include:

Open tools, PDKs and shared fabrication routes
Connecting chip layouts to boards and working hardware
Research, education and collaboration across the open silicon community Learn more and register here: outerfab.com/events/szoss/ Spread the word and let us know if you're coming!!

Since I see other folks posting their wins here, a major milestone for my Run 4 project: Linux 6.12 now boots to a shell on the RV64 core I'm taping out on Run 4: VexiiRiscv in a LiteX SoC, running on a Kintex-7 FPGA at 50 MHz for now. The goal for the chip is a fully open source GF180 SoC that runs stock Debian. The image is its current layout, overall still very much a WIP.

root@b0:~# uname -a
Linux b0 6.12.107 #1 SMP Mon Oct 12 14:06:39 UTC 2026 riscv64 GNU/Linux
root@b0:~# cat /proc/cpuinfo
isa             : rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd_sstc
mmu             : sv39

Also thanks to the VexiiRiscv, LiteX, and KianV (for their USB IP). (edited)

Second one, for Run 3: since it sold out, I scaled a project down to an RV32 MCU that fits a quarter slot (pre-thanks @Essen ). It's only in simulation so far: Zephyr boots to its shell on the full RTL, design based on a customized Hazard3 core at 24 MHz in Verilator. FPGA very soon. The image is the full die.

*** Booting Zephyr OS build v4.4.2-dccb09599635 ***

uart:~$ qstatus
Q1 ticks=0 uptime_ms=33
uart:~$ qgpio 8 1
uart:~$ qgpio 8
1

Based on a Hazard3 base, thanks to folks on that project

(edited)

Agenxy

Since I see other folks posting their wins here, a major milestone for my Run 4 project: Linux 6.12 now boots to a shell on the RV64 core I'm taping out on Run 4: VexiiRiscv in a LiteX SoC, running on a Kintex-7 FPGA at 50 MHz for now. The goal for the chip is a fully open source GF180 SoC that runs stock Debian. The image is its current layout, overall still very much a WIP.

root@b0:~# uname -a
Linux b0 6.12.107 #1 SMP Mon Oct 12 14:06:39 UTC 2026 riscv64 GNU/Linux
root@b0:~# cat /proc/cpuinfo
isa             : rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd_sstc
mmu             : sv39

Also thanks to the VexiiRiscv, LiteX, and KianV (for their USB IP). (edited)

@Agenxy this looks awesome. Would it be possible to share your project here ?

1

disdi89 (Saket Sinha)

@Agenxy this looks awesome. Would it be possible to share your project here ?

What would you be interested to see? Haven't yet thought through how to publicly share these projects yet, wondering which sources various audiences would want to see published. I planned to release XLS, verilog, RTL, modeling and sim files after bring-up, as well as write-ups: benchmarks, and high level architecture specs and docs, and of course the FW and drivers. Right now it's a mess of scripts linking my various tools together (trying to have eventually have a polished integrated e2e pipeline with as little replicated steps as possible from modeling, design, sims, place/route/STA and emu).

RTL design and Librelane flow with padring etc would be interesting for me

Agenxy

Second one, for Run 3: since it sold out, I scaled a project down to an RV32 MCU that fits a quarter slot (pre-thanks @Essen ). It's only in simulation so far: Zephyr boots to its shell on the full RTL, design based on a customized Hazard3 core at 24 MHz in Verilator. FPGA very soon. The image is the full die.

*** Booting Zephyr OS build v4.4.2-dccb09599635 ***

uart:~$ qstatus
Q1 ticks=0 uptime_ms=33
uart:~$ qgpio 8 1
uart:~$ qgpio 8
1

Based on a Hazard3 base, thanks to folks on that project

(edited)

Seems like you could squeeze some more on there

-# well done, seems pretty full

2

Yeah, turns out you can get so much done with a quarter slot. I really think it's the best size

I'm currently working on a half slot size. They all have their place :)

1

namibj

happy to have your hall structures in whatever muxed e-test hopefully happens soon. I think it's pretty prime targeting there, actually. It should probably be not placed where the COB mezzanine obstructs the die bottom though, but otherwise, pretty perfect. At least assuming that the hookups don't need to be high-frequency.

@Andrew Wingate @Tholin @namibj do you guys need another slot if analog pins are a bottleneck?

I'd have to look at what Tholin's doing with all the pins right now regarding whether we could steal/MUX enough of them for the "muxed e-test".

I want this chip to be pad-out compatible with my run 2 submission so its a drop-in replacement for the bring-up hardware I already got (which will save me a couple hundred dollars). As a result, there are no free analog pins.

ok, then maybe we can have a separate chip just for all of the analog goodies for nam and andrew?

11:27 a.m.

maybe we can find an interesting use for the 1/4 slot that advances the state of open source silicon

Someone managed to fit a RISC-V SoC into a quarter slot. I’m sure it can hold the muxed e-test.

Paul

@Andrew Wingate @Tholin @namibj do you guys need another slot if analog pins are a bottleneck?

I'm at IKEA rn planning to get some boxes and a like a kitchen ladle; then I planned to go to a mural at the bottom of the hill that the IKEA sits atop of and take a bunch of full resolution pictures of it with my phone to later stitch together in Hugin; it's a long one (65m wide and about 3m high at the tall end; I'll forward the discord image for clarity and in case anyone's curious). On the way back I'll restock on bakery bread that's not full of seeds (e.g. linseed and such; that I have a few freshly-cut-at-bakery loaves in the freezer) to eat for dinner and tomorrow, then when I'm home I guess I might as well get on and do the diagram-of-analog-MUX-with-stacked-m3&m4-both-going-crosswise task. I think it would be good to figure out what switch sizing would be best to do for specific DUT connections, I.e., it's looking like we could adjust where the boundary between the PMOS and NMOS rectangles is in the 2D-crosspoint array, and probably also adjust to make certain DUTs get wider (extend in the lengthwise direction along the analog bus; if you compare to gf180mcuD and sky130A TinyTapeout, my "lengthwise" is their horizontal and my "cross-wise" is their vertical, specifically referring to the analog MUX strips that reach inwards from the die edge and are connected top and bottom to analog user projects) switches for lower R_(on). At least slightly adjusting the area ratio between NMOS and PMOS based on what DUT pin they are for is something I feel would make a difference at least for some of the higher-current DUTs. Which, I guess, would likely be focused on some structures that are high-speed current-mode-logic-cells: [Elaboration cut for brevity; I spent already way too long rambling on this especially given it was done on phone keyboard sitting at the bus stop just prior to actually walking across the parking lot into the IKEA...]

12:23 p.m.

Paul

ok, then maybe we can have a separate chip just for all of the analog goodies for nam and andrew?

@Andrew Wingate the "analog goodies" referred to are primarily/essentially your 5 hall effect sensor DUTs (c.f. https://discord.com/channels/1361349522684510449/1361349523724570941/1563664093167095808 ), correct? If so, then I'm confident. I'd have to check the half slot uncut-split COB-default-opportunity bonding plan for compatibility, but it's likely we could also target "one half of an uncut half-height respectively half-width slot, only adjusting the pad frame "redistribution" to make up for the slightly different bond pad pitch and assignments of what shared-GND and what capacitor-having VDD-nets are. That'd be only for flexibility during late-stage https://platform.wafer.space submission, to perhaps have spare variants gone through filing and DRC in case any of the reserved slots fail to submit DRC-clean in-time. Or if you'd may want to re-group among your slot reservations, or such. I'd only look at the bond plans and briefly write a judgement/opinion btw., not actually put any "proper" work into it.

Welcome to wafer.space …

Platform for wafer.space low cost silicon manufacturing.

Paul

maybe we can find an interesting use for the 1/4 slot that advances the state of open source silicon

The spare area on Tholin's die could probably hold some kind of VCSEL or epc-co eGaN-FET power amplifier driving such a low-impedance load with flip chip access, if I can hurry enough to confirm the Run2 FC01 dies can successfully bond to at least JLCPCB's 1/3 oz 2L flex PCB (it's distinguished as having a truly low cost "MPW"-like prototyping offer, @Essen has some test "boards" for iirc a hypothetical full slot on I think just the COB special bond plan but critically taped out with the flip chip seal ring (that doesn't expose top metal pad along the ring just a dozen-ish micrometers from the exposed bond pad itself)).

namibj

The spare area on Tholin's die could probably hold some kind of VCSEL or epc-co eGaN-FET power amplifier driving such a low-impedance load with flip chip access, if I can hurry enough to confirm the Run2 FC01 dies can successfully bond to at least JLCPCB's 1/3 oz 2L flex PCB (it's distinguished as having a truly low cost "MPW"-like prototyping offer, @Essen has some test "boards" for iirc a hypothetical full slot on I think just the COB special bond plan but critically taped out with the flip chip seal ring (that doesn't expose top metal pad along the ring just a dozen-ish micrometers from the exposed bond pad itself)).

Or one could stuff an image sensor with digital IO in the area.

Tholin

Someone managed to fit a RISC-V SoC into a quarter slot. I’m sure it can hold the muxed e-test.

not quite understanding so there are no analog pins available but this is not a problem in @Tholin 's view but is in @namibj 's view?

Paul

not quite understanding so there are no analog pins available but this is not a problem in @Tholin 's view but is in @namibj 's view?

I feel Tholin might be thinking you have a separate quarter slot that's an individual die, not the bottom right quarter/corner of Tholin's digital/mixed Run3 die? (Notably to distinguish from Tholin's analog Run3 die.)

Paul

maybe we can find an interesting use for the 1/4 slot that advances the state of open source silicon

Yeah, I read this as meaning you have a separate quarter slot

1:00 p.m.

I can not provide any more analog pads as I have digital designs that need all 46 digital IOs and I’d like this chip to be pin-out compatible with my run 2 submission so I don’t go broke bringing it up.

Tholin

Yeah, I read this as meaning you have a separate quarter slot

Because, the "muxed e-test" requires around one to two dozen analog pins while being able to offer them MUXed similar to TinyTapeout for other purposes. If necessary, I could even have an (isolating from the dual-purpose analog pin's other task that would necessitate much reduced parasitic capacitance) series pass-gate between the fairly capacitive analog bus line (running length-wise along the crosspoint switch array that's the heart of the "muxed e-test") and the analog pad it's connected to. Especially if that'd be necessary to tape out on Run3.

I think you will need a dedicated tapeout for that many pads

ok, that’s no problem. let’s see what we can do with your remaining 1/4 slot

2:37 p.m.

we already have a team doing RISC V and USB 2.0 will announce soon

2:37 p.m.

so would have to be something else

Paul

so would have to be something else

AFAIK FlexMem bitcell got upgraded since Run2; if not otherwise covered that'd probably be a good fit.

any other ayes?

2:49 p.m.

(one other person saying yes it’s a good idea)

What’s FlexMem?

Paul

(one other person saying yes it’s a good idea)

@Chips4Makers aka Staf Verhaegen

Tholin

What’s FlexMem?

The SRAM compiler from Staf that's AFAIK the densest single port SRAM for sizes smaller than like 1mm^2 per macro we have.

2:52 p.m.

(at some point you'd need periphery capable of handling very long bitlines, and it's maybe a thing, but there's a decent chance FlexMem even if split into blocks and externally multiplexed still beats the larger area ones we got)

What’s the current limit for FlexMem? Like, the largest capacity single macro?

Tholin

What’s the current limit for FlexMem? Like, the largest capacity single macro?

I don't know how far the row decoder has been coded, but in theory, it should be very big. It's not hard macros, it's a compiler. And as it already takes care of inserting a row of taps every so often for DRC compliance, I don't think there's a layout schema limit to how many rows it should support to compile to with that very architecture/pattern. Access speeds should go down after a while, and I'm not sure if the sequencer can actually account for the needed higher wordline-to-sense-amplifier and write-precharge-to-wordline (unless it's realistically not necessary at all to precharge the bitlines ahead of a wordline activation for write purposes; I'd assume after some many rows the resistance of the bitline could possibly block the write driver transistors from overpowering a far-away bitcell if it doesn't pre-charge the bitlines to use their capacitance to overpower the bitcell right at activation), but that's it.

I have RTL for four custom microcontroller architectures that use an external ROM, but rely on on-die RAM that I could use to test this.

5:18 p.m.

(Holy f- I did not know it was that many until I counted just now!)

5:18 p.m.

(I may be a bit insane)

@Chips4Makers aka Staf Verhaegen could you please unbrick the build tooling for https://gitlab.com/Chips4Makers/arrakeen-sram-testchip/ , it seems you had written in a bunch of mentions of dev_SRAM branches strewn across the dependency web and it appears you've since deleted the branch which breaks uv. Notably, the mere uv run scripts/gen_views.py doesn't work and even trying to rewrite some of the lockfiles and even cloning and locally editing it's pyproject.toml of c4m-flexmem didn't suffice; next step would have been to clone and edit similarly PDKMaster to keep that as a dependency of c4m-flexmem from trying and failing to fetch @dev_SRAM of pdkmaster-io-spice.

Tholin

What’s the current limit for FlexMem? Like, the largest capacity single macro?

a 512x32 was the largest member taped out on the Run2 test dies; but as you see the project's build config isn't reproducible because someone did deletion work on branches I think.

AFAIK these are from bottom to top in that order (i.e., the vertical order between image and code is reversed). That's the 3v3 with SRAM DRC rules.

# SP
_fab = SPSRAMFactory(lib=memlib, sram_rules=True, name_prefix="SP6TR")
sp1 = _fab.block(words=128, word_size=8, we_size=1, cell_name="Block_128x8")
sp2 = _fab.block(words=256, word_size=16, we_size=2, cell_name="Block_256x16")
sp3 = _fab.block(words=512, word_size=32, we_size=4, cell_name="Block_512x32")

# DP
_fab = DPSRAMFactory(lib=memlib, sram_rules=True, name_prefix="DP8TR")
dp1 = _fab.block(words=128, word_size=8, we_size=1, cell_name="Block_128x8")
dp2 = _fab.block(words=256, word_size=16, we_size=2, cell_name="Block_256x16")
dp3 = _fab.block(words=512, word_size=32, we_size=4, cell_name="Block_512x32")

It's really not that large.

namibj

AFAIK these are from bottom to top in that order (i.e., the vertical order between image and code is reversed). That's the 3v3 with SRAM DRC rules.

# SP
_fab = SPSRAMFactory(lib=memlib, sram_rules=True, name_prefix="SP6TR")
sp1 = _fab.block(words=128, word_size=8, we_size=1, cell_name="Block_128x8")
sp2 = _fab.block(words=256, word_size=16, we_size=2, cell_name="Block_256x16")
sp3 = _fab.block(words=512, word_size=32, we_size=4, cell_name="Block_512x32")

# DP
_fab = DPSRAMFactory(lib=memlib, sram_rules=True, name_prefix="DP8TR")
dp1 = _fab.block(words=128, word_size=8, we_size=1, cell_name="Block_128x8")
dp2 = _fab.block(words=256, word_size=16, we_size=2, cell_name="Block_256x16")
dp3 = _fab.block(words=512, word_size=32, we_size=4, cell_name="Block_512x32")

It's really not that large.

so, in the quarter corner of a full slot, I'd eyeball about 1280x160, approximately?

namibj

@Chips4Makers aka Staf Verhaegen

hi @Chips4Makers aka Staf Verhaegen !

@everyone who ordered bare die from wafer.space Run #2 should have gotten a fedex tracking confirmation message yesterday for the shipment of the first ~200 bare die. If you haven't and think you should have, please poke me via email at tim@wafer.space I'm excited to see people bring up their projects! You can find out more about the various projects on Run #2 on the new pages @ https://wafer.space/ws-run2/ (edited)

wafer.space Run 2 — wafer.space

Designs, density statistics and layout renders from wafer.space GF180MCU Run 2.

I'm wondering who here is getting bare dies and has a public project ?

tnt

I'm wondering who here is getting bare dies and has a public project ?

technically me

8:55 a.m.

(kinda sort of)

tnt

I'm wondering who here is getting bare dies and has a public project ?

me

I know @namibj that's the FC01 right ? @судонет What's yours ?

tnt

I know @namibj that's the FC01 right ? @судонет What's yours ?

yeah

tnt

I know @namibj that's the FC01 right ? @судонет What's yours ?

AS16

@namibj What's your plan for testing that ?

tnt

@namibj What's your plan for testing that ?

gonna cook up the layout later today and get a pinned-out board for JLC's special offer 2L flex with the tightest DRCs on trace pitch they offer across their specials.

@судонет And you have access to a wire bonder ?

tnt

@судонет And you have access to a wire bonder ?

Not at all!

9:18 a.m.

Not even old enough to access one in a university, let alone have money for such services. (edited)

AS16 looks to be COB frame though?

namibj

AS16 looks to be COB frame though?

indeed!

I'm a bit confused then, because I was asking about people getting bare-dies / non-COB ?

tnt

I'm a bit confused then, because I was asking about people getting bare-dies / non-COB ?

ordered them as bare die, but still used default COB footprint.

10:12 a.m.

after all, I only had 3 days 'til tapeout

Yeah, I'm wondering what's your test plan then ?

tnt

Yeah, I'm wondering what's your test plan then ?

essentially nonexistent, at the moment

@Tim 'mithro' Ansell Which PCB manufacturer were you talking to about offering COB ?

tnt

@Tim 'mithro' Ansell Which PCB manufacturer were you talking to about offering COB ?

NextPCB